Create and Maintain Relationships using Business Rules

Ability is provide via attached business rules to address the below four requirements:
• Adding a relationship for a new client record (relating to an existing client/group customer record) being created: adding the first relationship time slice.
• Adding a new relationship between two existing client/group customer records.
• Adding a new timeslice to an existing client relationship record.
• Editing an existing active timeslice on an existing client relationship record
Creating Relationship via Create Client Business Rules:
1. PRIMARYTYPE – specifies the primary relation between the client being created and an existing client
2. SECONDARYTYPE – specifies the secondary relation between the client being created and an existing client3.
3. PRIMARYGUID – The attribute PRIMARYGUID in the <Relationship> element is optional.

a. Between the PRIMARYGUID and SECONDARYGUID, one attribute should always be provided. The other value will be substituted with the ClientGUID of the client being created for the purposes of the Relationship record.
b. If both PRIMARYGUID and SECONDARYGUID are provided or both attributes are not provided, a system error will be displayed with a message saying "Only one of PRIMARYGUID and SECONDARYGUID attributes should be provided"

4. SECONDARYGUID - The SECONDARYGUID will be an optional attribute which can be provided when the new client being created should become the Primary Client for the relationship.

a. Basis the values provided under the PRIMARYGUID (identify PrimaryClientType basis this), SECONDARYGUID (identify SecondaryClientType basis this),

b. PRIMARYTYPE (this is mapped to the PrimaryRelationshipTypeCode) and SECONDARYTYPE (this is mapped to the SecondaryRelationshipTypeCode) attributes, the ClientRelationshipScreen BR relating at the Primary Company override level should be used to check the validity of the relationship combination.

c. If invalid, a system error should be displayed with a message saying "Invalid Relationship combination (PrimaryClientType, SecondaryClientType, PrimaryRelationshipTypeCode, PrimaryRelationshipTypeCode)".

5. RECORDSTATUSCODE - The RECORDSTATUSCODE attribute will allow two possible values - ACTIVE and DRAFT (linked with AsCode table for AsCodeChangeStatus). This will link to the RecordStatusCode of the client relationship timeslice. Only Active and Draft status time slices can be added.

a. This is a optional attribute and the default value, if this attribute is not configured will be ACTIVE.
b. The RecordStatusCode cannot be used in the <Fields> section under the relationship element since it is available as an attribute

6. BUSINESSSTATUSCODE – Used to capture the business status code in case it is being used
EFFECTIVEFROM - Used to capture the EffectiveFrom date of the Relationships

When the CreateClients BR is processed with a valid Relationship element, a relationship record will be created with one time slice for the same.

If the time slice is set with RecordStatusCode is set to "DRAFT", the relationship time slice can then be edited/submitted from the OIPA application UI like any other time slice created from UI.

If the time slice is set with RecordStatusCode set to "ACTIVE", the relationship time slice will be created in "PENDING" status and the attached BR will create the associated Screen Update Activity with the following points taken care of:

a. The ClientRelationshipScreen BR at the Primary Company level will need to referenced to identify the Screen Update Activity to be spawned for this particular

combination of Primary Relationship type, Secondary Relationship type.
b. The Screen Update activity will need to be spawned on the TimeSlice context.
c. The Screen Update activity will be created with EffectiveDate = EffectiveFromDate of the time slice.
d. The Screen Update activity will be linked with a "Change Request" entry to ensure the screen update activity and the time slice are linked appropriately.
e. The Screen Update activity will need to be "AUTO-PROCESSED" unless the Effective From Date is in future of the System Date.

f. All the attributes provided will be linked to the fixed Relationship fields and the <Fields> configured will be linked to the dynamic Relationship fields to create the

Relationship time slice with the appropriate relationship fields. The EffectiveToDate will be set to 12/31/9999 (maximum date entry).

Creating/Maintaining Relationship via Maintain Relationship Business Rules:

This attached Business Rule will beavailable under the Rules Palette Global Rules Explorer -> Business Rules -> Attached Rules.This BR will need to be added to the TransactionBusinessRulePacket when configured in a transaction
1. The MaintainRelationships BR will allow for a <Relationship> element (which is a repeatable element) under the <Relationships> element (available under the opening and closing tag for the rule). The <Relationship> element will allow the following attributes:

PRIMARYGUID - pertaining to the PrimaryClientGUID for the Relationship record.
SECONDARYGUID - pertaining to the SecondaryClientGUID for the Relationship record.
PRIMARYTYPE - pertaining to the Primary Relationship Type Code for the Relationship record.
SECONDARYTYPE - pertaining to the Secondary Relationship Type Code for the relationship record.
EFFECTIVEFROM - pertaining to the Effective From Date for the relationship record.
RECORDSTATUSCODE - pertaining to the Record Status Code for the relationship record.
This attribute will allow only two values - ACTIVE and DRAFT (linked with AsCode table for AsCodeChangeStatus). This will link to the RecordStatusCode of the client relationship timeslice.
Only Active and Draft status time slices can be added.
This is an optional attribute and the default value, if this is not configured, will be ACTIVE.
BUSINESSSTATUSCODE - pertaining to the Business Status Code
Basis the PrimaryClientType (Client type of the PRIMARYCLIENTGUID), SecondaryClientType (ClientType of the SECONDARYGUID), PrimaryRelationshipTypeCode (PRIMARYTYPE attribute) and SecondaryRelationshipTypeCode (SECONDARYTYPE attribute), the ClientRelationshipScreen BR relating at the Primary Company override level will be used to check the validity of the relationship combination. If invalid, a system error should be displayed with a message saying "Invalid Relationship combination (PrimaryClientType, SecondaryClientType, PrimaryRelationshipTypeCode, PrimaryRelationshipTypeCode)".

2. The <Relationship> element will allow <Tests> tag with repeatable <Test> elements for setting up test conditions based on which the relationship record will be executed.

3. This will behave similar to other Test elements. If all the configured test conditions are satisfied, the relationship record will be processed else skipped.

4. The <Relationship> element will allow <Fields> tag with repeatable <Field> elements to define the relationship field values for the relationship record using the <From> and <To> elements similar to other <Fields> elements for maintaining entity records.

5. All fixed fields except PrimaryClientGUID, SecondaryClientGUID, PrimaryRelationshipTypeCode, SecondaryRelationshipTypeCode, EffectiveFrom, EffectiveTo and RecordStatusCode will be available for configuring values under the <Fields> tag.

6. All dynamic fields of the relationship record are available for configuring values to be copied.

7. If any of the <Fields> configured are not applicable for the specific PrimaryClientType, SecondaryClientType, PrimaryRelationshipTypeCode and SecondaryRelationshipTypeCode combination, a system error will be displayed.

Error message "Unable to copy field to the targeted Relationship : Field : <FieldName>"

8.When the MaintainRelationships Business Rules is processed with a valid Relationship element, the system will identify whether the client relationship already exists/not, and accordingly behave as follows:
Using the PrimaryClientGUID (PRIMARYGUID attribute), SecondaryClientGUID (SECONDARYGUID attribute), PrimaryRelationshipTypeCode (PRIMARYTYPE attribute) and SecondaryRelationshipTypeCode (SECONDARYTYPE attribute), identify if a Client Relationship exists. Basis the same,

If relationship doesn't exist. In this case, a new relationship record will be created with the first time slice.

If relationship already exists. In this case, basis ClientRelationshipParentGUID from the above combination, identify whether a client relationship time slice for the EffectiveFromDate (EFFECTIVEFROM attribute) already exists/not and if exists, pickup the status of the time slice(s). Based the same,

No time slice exists. In this case, a new time slice record needs to be created.

Time slice already exists in "Draft" or "Pending" status (this scenario includes a case where one Active time slice + one time slice in Draft or Pending status already exists): A system error is thrown saying "A Draft or Pending time slice exists for the same relationship with the same EffectiveFromDate. Another time slice for the same relationship record with same EffectiveFromDate cannot be created".

Time slice already exists in "Active" status: A new time slice record needs to be created. This is the equivalent of Editing the Active time slice.

When a Client Relationship time slice is created from the MaintainRelationships BR:

If the time slice is set with RecordStatusCode is set to "DRAFT", the relationship time slice can then be edited/submitted from the OIPA application UI like any other time slice created from UI.

If the time slice is set with RecordStatusCode set to "ACTIVE", the relationship time slice will be created in "PENDING" status and the attached BR will create the associated Screen Update Activity with the following points taken care of:

The ClientRelationshipScreen BR at the Primary Company level will be referenced to identify the Screen Update Activity to be spawned for this particular combination of Primary Relationship type, Secondary Relationship type.

The Screen Update activity will need to be spawned on the TimeSlice context.

The Screen Update activity will be created with EffectiveDate = EffectiveFromDate of the time slice.

The Screen Update activity will be linked with a "Change Request" entry to ensure the screen update activity and the time slice are linked appropriately.

The Screen Update activity will need to be "AUTO-PROCESSED" unless the Effective From Date is in future of the System Date.

All the attributes provided will be linked to the fixed Relationship fields and the <Fields> configured will be linked to the dynamic Relationship fields to create the Relationship time slice with the appropriate relationship fields.

If an existing client relationship is being edited and any of the dynamic fields are not configured under the <Fields> tag, such field values will be picked up from the previous time slice (chronologically previous value considering the EffectiveFrom date). This is similar to the scenario where we edit a time slice or create a new time slice to an existing client relationship - default value of all fields is picked up from the previous time slice.

If an existing client relationship time slice (in Active status) is being edited and all dynamic field values provided now is same as what is existing in the previous Active time slice, the Relationship record should be ignored and no new time slice should be created but no error should also be displayed.
In case the activity with MaintainRelationships attached BR is reversed, the relationship time slice will be moved to “SHADOW” and the time slice activity created from the attached BR should also be reversed to “12" - Shadowed status.